%GUIDELINES:
% make the requirement not to concrete to give us the ability to 'reinterpret' them on the fly


\chapter{Interpretation of the requirements from the set A}

\section{Process handling}

\subsection*{Process states}
%This requirement means that we have to have a way to block or delay a process. So, we must have be able to distinguish between ready and blocked processes. That means that we must include a process state in our process definition.  

%Besides, we need a waiting queue to store the processes that are blocked or delayed and make sure that they are not scheduled and cannot execute any code. We will also need a way to wake processes up either after a given amount of time or when a certain event occur.

%[VW] modified suggestion
A process is a program in execution. The Operating System (OS) to be implemented, needs to provide methods to distinguish between processes' different states. These states are at least \emph{ready} and \emph{blocked}, which gives the operating system the ability to defer a processes' execution. Different processes that are not presently executing need to be kept in an adequate data structure. A capability to control whether a process is active on the CPU or not must be included in the OS, to respond to various events that might occur in the system. Examples of the events inculde triggered interrupts, especially by a timer.    

\subsection*{Process priorities}
%Since we will be using priority scheduling, the processes will have a priority level. We must provide a way to change the priority of a process at run-time.

%[VW] modified suggestion
It is favourable to associate priorities with every process, which are changeable at runtime. This is required for priority scheduling among processes in the OS.

\subsection*{Process scheduling}
%We must use preemptive priority scheduling in our OS. So, the highest priority process will always be the one executing. If a lower priority process is executing when the high priority one arrives, the latter preempts it and begins running. 

%If we have several processes with the highest priority level, round-robin will be used among them. That means that each of these processes will get a time quantum during which it executes. At the end of this quantum, the process is preempted and another eligible process gets to execute (here, one of the highest priority processes).

%[VW] modified suggestion
%TODO: Please look at this, it does not say that we will implement RR. It says we will implement some preemptive scheduling with priorities.
Preemptive scheduling, e.g Round Robin (RR) is a desired feature of the OS to be implemented. CPU time assigned to a process through our OS Process Scheduling orients itself on the according process' priority, that is, the highest priority processes will always get to run before the lower priority ones. RR scheduling will be used to schedule processes with the same priority. 

\subsection*{Process identities}
%Each process must have an identity, like the process pid on Linux. This identity will be used to accesses processes (to set the priority for example).

A process must be unambigously identifiable within the OS. This might be provided through a unique process's id (pid).
A human-readable name of a process identifier is favorable.

\subsection*{Process creation}
%This requirement asks us to provide support for functions like fork() and exec(). So, the OS will have to provide system calls for this purpose.

%Processes can be created using a spawn process function. This function will return the id of the created process and should report any error happening during process creation. This function must also allow processes themselves to spawn child processes.

The OS should provide an API with functions that allow processes to start other (child-)processes on runtime, similar to fork() and exec() in Linux. 

\subsection*{Process termination}
%The fact that processes must be able to terminate themselves means that our OS have to provide a system call like the exit() system call in C.

%We must also provide a system call enabling processes to terminate others processes. Of course, the OS itself will have to be able to do the same with any process. The biggest difference is that OS will not need to use the system calls.

Processes can terminate themselves, e.g. by using the exit() system call. This will make contol flow return to the OS. Moreover other processes and the OS itself should be able to terminate processes. On a process level this can only be granted through system calls.

\subsection*{Programs and processes}
%Programs are executable files on a hard drive. 
%Processes are programs in execution. %already mentioned above

%A process runs the code of a program. This requirements means that the OS must provide a way to execute programs, that is to create a process executing the code of the chosen program.
 
%Programs must have a name and an ID to identify them. This information will be used to start the execution of a program (like the ./program\_name on Linux). %this belongs to the section 'process identities'

%REMARK:this is directly from PingPong without the parts on process identities
Each process runs the code of one particular program.  The program to execute in a process is specified when the process starts.

There should be a global table of available programs and it should be possible to start every program in multiple simultaneous instances.


\subsection*{Process information}
%A process must have a way to consult other process' PCB to get the information in it. We have then to provide a system call for this. The fact that information must be readable by the process requesting it means that we must decide on a way to store information that will never change between processes, that is the layout of the PCB does not vary.

System calls are to be provided that help processes gain information about other processes.
 
Examples of which kind of information is has to be exchangable amongst processes are:
process priority, process name, name of the program running in the process and current scheduling state of the process


\subsection*{Resource recycling}
The OS must make sure to get back any resource that was used by a terminated process. It must not be possible that the process keeps resources indefinitely after it has finished. 

When a process terminates, its identification must be reusable. Thus, another process started later will be able to use this ID. 

\subsection*{Process limitations}
%Since we do not have an OS, we do not have any way to allocate memory dynamically unless we create it. So, it will be useful, at least at the beginning, to use fixed sized structures because there is no need for dynamic allocation in this case. 

%Using \textit{\#define} to set these upper bounds will allow easy modifications of them, either by a programmer who wants to check its code with several settings or by a teacher who wants to make sure that the system will work with another value.

There can be a fixed but arbitrary upper limit on the number of processes allowed in the  system.
Any fixed upper limits must be easy to modify, using a $\#$-define or similar C construct.


\section{Input and output}

\subsection*{Text consoles}
%Our system has to provide at least one text console. This console will be used to start processes and read their output. We can easily imagine some kind of Linux-like console here where the user types commands to start processes and gets his results via the very same console.

The system should provide at least one text console for input and output.

\subsection*{Interrupt-driven I/O}
%I/O will be implemented using interrupts and not some other technic like polling. So, the system will be informed of the completion of an I/O using interrupts.

I/O shall be implemented using interrupt-driven IO on the serial port of the system.

\subsection*{Text output}
Processes must be able to print messages on the console. These messages must be printed in a coherent way, that is, if two processes wants to print messages at the same time, it results in the two messages being printed one after another and not in some interleaved way. 
This output will need a system call to be done (like printf()).

\subsection*{Text input}
The process must be able to get information from the user if needed. To do that, we must provide a system call being able to read the input and to give it to the process which has requested it. We will probably need to have an upper bound of the size of an input. 

\subsection*{Malta LCD output}
The OS should provide a system call for the processes to print on the Malta LCD.  

\section{System API}

\subsection*{General}
There must be no way to request the services from the kernel other than through the functions provided by the API. 
%It is then impossible for a user program to use the kernel functionalities directly. 

\subsection*{Syscall}
MIPS uses exceptions to manage system calls. This feature must be used to implement system calls in this case.    

\subsection*{Documentation}
%To make the use of the API easier, a documentation describing it must be provided with the deliverables at the end of the project.

The API shall be delivered together with a documentation describing all it's functions.

\section{Other}

%REMARK: Isn't it kind of stupid to write a non-requirement in the requirement list?
\subsection*{No shared memory}
%Processes should not use shared memory as a mean to communicate between them. It is however not required that the OS investigates each process to make sure that this requirement is respected. We have trustworthy programmers!

Processes should never use shared variables or memory to communicate.
Albeit it is not necessary for the operating system to enforce this condition.

\subsection*{Reetrancy}
It must be possible to run several instances of a same program at the same time. That means that the code of a reetrant program does not modify itself and that each process executing it has its own copy of the program variables.

\subsection*{Error handling}
System calls must return a code indicating whether they failed to do their task or not. The OS may also provide a functionality printing diagnostic messages to the console after an error (like perror()).

%\section{User programs}
%There is nothing to say here. We just have to provide some programs using our API and doing the requested tasks. Those programs will show that the OS works. 

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "main"
%%% End: 
